태그 등 일반 텍스트로 표현하기 어려운 서식은 의도적으로 문법에서 제외되었다. 대신, 마크다운은 이러한 고급 서식이 필요할 경우 사용자가 주저 없이 HTML 태그를 직접 문서에 삽입하도록 권장한다. 마크다운 파서는 문서 내의 HTML 블록을 인식하고, 그 내부에서는 마크다운 문법을 처리하지 않은 채 그대로 통과시킨다. 이는 마크다운의 한계가 아니라, 단순성을 유지하면서도 필요할 때 HTML의 모든 기능을 활용할 수 있도록 열어둔 의도된 설계의 일부이다.10

2.4 표준화에 대한 회의적 시각과 그 영향

마크다운이 인기를 얻고 다양한 구현체들이 등장하면서, 문법의 모호한 부분들을 명확히 하고 기능을 확장하기 위한 표준화 요구가 자연스럽게 생겨났다.8 그러나 창시자인 그루버는 이러한 움직임에 회의적이었고, 완전한 표준화가 오히려 실수일 것이라고 주장했다. 그는 “서로 다른 사이트와 사람들은 각기 다른 필요를 가진다. 단 하나의 문법이 모두를 행복하게 할 수는 없다“고 언급하며, 마크다운의 유연성을 해칠 수 있는 경직된 표준화에 저항했다.8

이러한 창시자의 철학은 마크다운의 역사에 지대한 영향을 미쳤다. 그루버의 비전은 마크다운을 특정 요구에 맞춰 자유롭게 변형하고 확장할 수 있는 작고 유연한 도구로 남겨두는 것이었다. 하지만 이러한 철학적 입장은 결과적으로 마크다운의 가장 큰 약점으로 지적되는 ‘파편화(fragmentation)’ 문제의 근본적인 원인이 되었다. 창시자가 표준을 확립하고 발전시키는 데 소극적인 태도를 보이자, 테이블, 각주, 구문 강조와 같은 추가 기능이 필요했던 개발자들은 자연스럽게 자신들의 필요에 맞춰 독자적인 확장 문법, 즉 ’플레이버(flavor)’를 만들어내기 시작했다.13 결국, 마크다운의 강점인 단순성과 유연성을 지키려던 창시자의 철학이 역설적으로 생태계의 혼란과 비호환성을 야기하는 씨앗이 된 것이다. 커뮤니티의 실용적 요구와 창시자의 개인적 비전 사이의 이러한 괴리는 이후 CommonMark와 같은 표준화 노력의 직접적인 동기가 되었다.

3. 핵심 문법 체계 분석

3.1 기본 구성 요소

존 그루버의 원본 설계에 명시된 핵심 문법 요소들은 마크다운의 근간을 이루며, 현재 존재하는 거의 모든 마크다운 애플리케이션에서 공통적으로 지원하는 기반을 형성한다.15 각 문법은 ’가독성’이라는 최우선 원칙에 따라, 일반 텍스트 환경에서도 그 의미가 직관적으로 파악되도록 설계되었다.

• 제목 (Headers): 문서의 계층 구조를 표현하기 위해 사용된다. 줄 시작 부분에 # 기호를 사용하며, 그 개수에 따라 HTML의 <h1>부터 <h6>까지의 제목 수준에 대응된다. 예를 들어, ## Section Title은 <h2>Section Title</h2>로 변환된다. 또한, 텍스트 아래에 여러 개의 등호(=)나 하이픈(-)을 사용하여 각각 1단계와 2단계 제목을 만드는 Setext 방식도 지원한다. 이는 문서의 개요를 시각적으로 명확하게 드러내는 역할을 한다.17
• 단락 및 줄 바꿈 (Paragraphs and Line Breaks): 하나 이상의 연속된 텍스트 줄은 하나의 단락으로 취급되며, 단락과 단락 사이는 하나 이상의 빈 줄로 구분된다.19 이는 시각적으로 단락을 구분하는 가장 보편적인 방식을 그대로 문법으로 채택한 것이다. 단락 내에서 강제로 줄을 바꾸고 싶을 경우(HTML의 <br> 태그 생성), 줄의 끝에 두 칸 이상의 공백을 삽입하고 엔터 키를 누른다.21 이는 WYSIWYG 편집기처럼 단순 엔터가 줄 바꿈으로 즉시 반영되는 것과 달리, 작성자의 명시적인 의도를 요구하여 의도치 않은 줄 바꿈을 방지한다.
• 강조 (Emphasis): 텍스트를 강조하는 기능은 이메일 등에서 널리 쓰이던 관행을 그대로 가져왔다.10 텍스트를 하나의 별표(*) 또는 밑줄(_)로 감싸면 이탤릭체(HTML의 <em> 태그)로 변환되고, 두 개의 별표(**) 또는 밑줄(__)로 감싸면 굵은 글씨체(HTML의 <strong> 태그)로 변환된다.17 이 기호들을 세 개씩 중첩하여(*** 또는 ___) 굵은 이탤릭체를 표현할 수도 있다.16
• 목록 (Lists): 순서가 있는 목록과 없는 목록을 모두 지원한다. 순서 있는 목록은 1., 2., 3.과 같이 숫자와 마침표로 각 항목을 시작한다. 이때 숫자의 순서는 실제 렌더링 결과에 영향을 주지 않으며, 파서는 자동으로 순번을 매긴다.22 순서 없는 목록은 별표(*), 더하기 기호(+), 하이픈(-) 중 하나를 사용하여 항목을 시작한다.20 목록 항목을 들여쓰기(indentation)하면 중첩된 하위 목록을 생성할 수 있어, 복잡한 계층 구조도 표현 가능하다.19
• 링크 (Links): 웹 문서의 핵심 요소인 하이퍼링크를 위해 두 가지 스타일을 제공한다. 첫째는 인라인(Inline) 스타일로, [링크 텍스트](URL%20"선택적%20제목") 형식으로 작성된다. 이는 링크와 URL이 함께 있어 직관적이다. 둘째는 참조(Reference) 스타일로, 본문에는 [링크 텍스트][라벨] 형식으로 간결하게 표시하고, 문서의 다른 곳(주로 하단)에 [라벨]: URL "선택적 제목" 형식으로 URL 정의를 모아둔다. 이 방식은 긴 URL이 본문의 가독성을 해치는 것을 방지하고, 동일한 URL을 여러 번 재사용할 때 유용하다.20
• 이미지 (Images): 이미지 삽입 문법은 링크와 매우 유사하며, 단지 맨 앞에 느낌표(!)를 추가하는 차이가 있다. ![대체 텍스트](이미지_경로%20"선택적%20제목") 형식으로 사용된다. 대체 텍스트는 이미지를 불러오지 못했을 때나 스크린 리더 사용자를 위해 표시되는 중요한 정보이다.17
• 인용 (Blockquotes): 다른 사람의 글이나 문서를 인용할 때 사용하며, 이메일 답장에서 원문을 인용하는 형식을 그대로 차용했다.10 인용할 텍스트의 각 줄 앞에 > 기호를 붙여 표현하며, >>처럼 기호를 중첩하여 중첩된 인용문을 만들 수도 있다.16
• 코드 (Code): 기술 문서에서 코드와 일반 텍스트를 명확히 구분하기 위한 문법이다. 문장 내의 짧은 코드나 명령어는 백틱(backtick, ```)으로 감싸 인라인 코드로 표현한다. 여러 줄로 이루어진 코드 블록은 각 줄을 4칸 이상 들여쓰기(또는 1개의 탭)하여 생성한다. 이는 코드가 일반 텍스트와 다른 형식임을 시각적으로 명확히 구분해준다.17
• 수평선 (Horizontal Rules): 문서의 구획을 시각적으로 나누기 위해 사용된다. 한 줄에 별표, 하이픈, 또는 밑줄을 3개 이상 연속으로 입력하면 HTML의 <hr> 태그로 변환된다 (예: ***, ---, ___).17

2.2. 초기 구현의 모호성과 해석의 여지

존 그루버의 원본 마크다운 명세는 공식적이고 엄격한 기술 사양이라기보다는 비공식적인(informal) 가이드에 가까웠다. 이로 인해 명세 자체에 여러 모호함(ambiguities)과 명확히 정의되지 않은 부분들이 존재했다.8 예를 들어, 서로 다른 문법 요소가 충돌할 때 어떤 것을 우선적으로 처리해야 하는지에 대한 우선순위(precedence) 규칙이 명시되지 않았다.

*강조*와 링크가 중첩될 때와 같은 엣지 케이스(edge case)에서 파서마다 다른 결과를 내놓는 원인이 되었다.26 또한, 목록의 들여쓰기나 공백 처리와 같은 세부 사항에 대한 규정이 부족하여 구현체 간에 미묘하지만 중요한 차이점을 낳았다.21

이러한 모호성은 단지 버그나 결함으로만 볼 수는 없다. 이는 마크다운의 탄생 배경과 철학에서 비롯된 의도된 특성이기도 했다. 마크다운은 엄격한 규칙보다는 이메일 등에서 사용되던 비공식적 관례에서 영감을 얻었기 때문에, 애초에 어느 정도의 유연성을 내포하고 있었다.9 이 유연성은 초기 생태계 확장에 긍정적인 역할을 했다. 엄격한 중앙 표준이 없었기 때문에, 각 플랫폼 개발자들은 자신들의 특정 요구(예: 테이블, 각주 지원)에 맞춰 마크다운을 자유롭게 해석하고 확장할 수 있었다. 즉, 모호함에서 비롯된 유연성이 다양한 ’플레이버’가 탄생하고 성장하는 토양이 된 것이다. 마크다운의 유기적이고 탈중앙화된 성장은 바로 이 특성 덕분이었다. 그러나 이러한 개별적인 진화가 서로 다른 시스템 간의 상호운용성(interoperability)을 요구하는 단계에 이르렀을 때, 모호함은 더 이상 장점이 아닌 심각한 문제로 부상했고, 이는 결국 CommonMark와 같은 표준화 노력의 필요성을 대두시켰다.

제3장: 표준화의 딜레마와 ’Flavor’의 시대

3.1. 파편화의 심화

창시자 존 그루버의 표준화에 대한 소극적인 태도와 원본 명세의 내재된 모호성은 필연적으로 마크다운 생태계의 ’파편화(Fragmentation)’를 심화시키는 결과를 낳았다. 마크다운의 인기가 높아지면서 수십 개의 서로 다른 프로그래밍 언어로 구현된 파서들이 등장했고, 이들은 각기 다른 방식으로 엣지 케이스를 처리하고 독자적인 확장 문법을 추가했다.8

이러한 상황은 마크다운의 핵심 가치 중 하나인 ’이식성(portability)’을 심각하게 훼손했다. 동일한 마크다운 문서임에도 불구하고 어느 플랫폼에서 보느냐에 따라 렌더링 결과가 달라지는 문제가 비일비재하게 발생했다. 이는 마크다운의 가장 큰 단점으로 꾸준히 지적되어 왔다.13 이러한 구현체 간의 차이를 시각적으로 비교하고 분석하기 위해, 여러 파서의 렌더링 결과를 한눈에 보여주는 Babelmark와 같은 온라인 도구가 등장하기도 했다. 이는 파편화 문제가 개발자 커뮤니티 내에서 얼마나 심각하게 인식되었는지를 보여주는 방증이다.8

3.2. ’Flavor’의 정의와 양면성

’플레이버(Flavor)’는 원본 마크다운 문법을 기반으로 하면서, 특정 기능(예: 표, 각주, 작업 목록 등)을 추가하거나 기존 문법의 해석 방식을 일부 수정한 파생 버전을 지칭하는 용어이다.29 이러한 플레이버의 등장은 마크다운 생태계에 양면적인 영향을 미쳤다.

긍정적인 측면에서, 플레이버는 마크다운의 기능적 한계를 극복하고 특정 도메인의 복잡한 요구사항을 충족시키는 데 결정적인 역할을 했다. 예를 들어, GitHub이 개발한 GitHub Flavored Markdown(GFM)은 테이블, 코드 블록 구문 강조, 작업 목록 등의 기능을 추가하여 소프트웨어 개발 문서 작성에 최적화된 환경을 제공했고, 이는 GFM을 사실상의 표준으로 만드는 성공 요인이 되었다.13 이처럼 플레이버는 마크다운의 적용 범위를 넓히고 생태계를 풍성하게 만드는 원동력이었다.

반면 부정적인 측면은 명확했다. 각 플레이버는 자신만의 고유한 문법을 가지므로, 플레이버 간의 호환성은 보장되지 않았다. MultiMarkdown으로 작성된 문서를 GFM 파서로 열거나, 그 반대의 경우 일부 서식이 깨지거나 의도와 다르게 표시될 수 있었다. 이는 사용자를 특정 플랫폼이나 도구에 종속시키는 결과를 낳았으며, “어디서든 쓸 수 있다“는 마크다운의 근본적인 약속을 위협했다.13

Table 1: 주요 마크다운 파생 문법(Flavor) 비교

기능	Gruber Markdown (원본)	CommonMark	GitHub Flavored Markdown (GFM)	Markdown Extra	MultiMarkdown (MMD)	R Markdown
펜스 코드 블록	✗	✓	✓	✓	✓	✓
표	✗	✗	✓	✓	✓	✓
작업 목록	✗	✗	✓	✗	✗	✓
취소선	✗	✗	✓	✗	✓	✓
자동 링크 (URL)	✗	✗	✓	✗	✓	✓
각주	✗	✗	✗	✓	✓	✓
정의 목록	✗	✗	✗	✓	✓	✓
수학식 (LaTeX)	✗	✗	✗	✗	✓	✓
메타데이터 블록	✗	✗	✗	✗	✓	✓
상호 참조	✗	✗	✗	✗	✓	✓

주: 위 표는 각 Flavor의 핵심적인 확장 기능을 요약한 것이며, 세부 구현은 다를 수 있다. CommonMark는 핵심 명세 자체에는 확장 기능이 없으나, 많은 GFM 기능이 CommonMark 기반 파서의 확장으로 구현된다.

자료 출처: 14

제4장: CommonMark: 통일성을 향한 여정

4.1. 등장 배경 및 목표

2014년, 마크다운 생태계의 고질적인 파편화와 모호성 문제를 해결하기 위한 구체적인 움직임이 시작되었다. Pandoc의 개발자로 유명한 존 맥팔레인(John MacFarlane)을 비롯한 개발자 커뮤니티는 CommonMark 프로젝트를 출범시켰다.8 이 프로젝트의 초기 명칭은 ’Standard Markdown’이었으나, 마크다운의 창시자인 존 그루버가 ’Markdown’이라는 이름의 사용에 반대하면서 현재의 ’CommonMark’로 변경되었다.8

CommonMark의 핵심 목표는 명확했다. 첫째, 마크다운 문법에 대한 매우 상세하고 모호하지 않은 명세(unambiguous specification)를 확립하는 것이다. 둘째, 이 명세를 기준으로 구현체의 정확성을 검증할 수 있는 포괄적인 테스트 스위트(test suite)를 제공하는 것이다. 셋째, C와 JavaScript로 작성된 고성능 참조 구현체(reference implementation)를 제공하여 다른 개발자들이 이를 기반으로 안정적인 파서를 만들 수 있도록 돕는 것이었다.8

4.2. CommonMark 명세의 특징

CommonMark는 기존에 없던 새로운 문법을 창조하는 것을 목표로 하지 않았다. 대신, 지난 10년간 다양한 환경에서 실제로 사용되어 온 마크다운의 용례를 수집하고 분석하여, 이를 바탕으로 “합리화된 버전(rationalized version)“을 정의하는 데 중점을 두었다.34 즉, 이론적인 완벽함보다는 현실적인 합의점을 찾는 데 초점을 맞춘 것이다.

CommonMark 명세의 가장 큰 특징은 그 철저함에 있다. 명세는 600개가 넘는 방대한 양의 예시를 포함하고 있으며, 각 예시에 대해 입력된 마크다운 텍스트와 그에 대응하는 정확한 HTML 출력 결과를 명시적으로 정의한다.27 이를 통해 과거에 모호하게 여겨졌던 모든 엣지 케이스, 예를 들어 목록 항목이 단락을 중단시키는 조건, 강조 문법의 복잡한 우선순위 규칙, 공백과 탭의 처리 방식 등을 명확하게 규정했다.36 이로써 파서 개발자들은 더 이상 모호한 부분을 추측에 의존해 구현할 필요가 없어졌고, 명세와 테스트 스위트를 통해 구현체의 일관성을 객관적으로 검증할 수 있게 되었다.

4.3. 생태계에 미친 영향

CommonMark의 등장은 마크다운 생태계에 지대한 영향을 미쳤으며, 파서 개발의 새로운 기준점이 되었다. GitHub, GitLab, Reddit, Stack Overflow와 같은 주요 플랫폼들이 CommonMark를 자신들의 마크다운 처리 방식의 기반으로 채택하거나, 이를 기반으로 자체 플레이버를 재정의하기 시작했다.33 특히 GitHub의 GFM이 CommonMark를 엄격한 상위 집합으로 정의한 것은 매우 상징적인 사건이었다.33

또한, C로 작성된 고성능 파서 cmark와 JavaScript 구현체 commonmark.js의 등장은 개발자들이 이전보다 훨씬 빠르고 안정적으로 마크다운 지원 기능을 자신들의 애플리케이션에 통합할 수 있게 해주었다.33 CommonMark는 파편화 문제를 완전히 종식시키지는 못했지만, 그 양상을 근본적으로 바꾸었다.

CommonMark의 진정한 역할은 모든 플레이버를 대체하는 ’단 하나의 표준’이 되는 것이 아니었다. 오히려, 그것은 다양한 플레이버들이 공존할 수 있는 안정적인 ‘기반 계층(foundational layer)’ 또는 ’공용어(Lingua Franca)’를 제공하는 것이었다. 이전에는 각 플레이버가 중구난방으로 존재했다면, CommonMark 이후에는 “CommonMark + 확장 기능“이라는 훨씬 더 예측 가능하고 안정적인 모델로 플레이버를 정의할 수 있게 되었다. 즉, CommonMark는 파편화를 끝낸 것이 아니라, 표준화된 핵심을 제공함으로써 파편화를 ‘길들인(tamed)’ 것이다. 이는 마크다운 생태계가 한 단계 더 성숙해지는 중요한 전환점이 되었다.

제5장: 주요 파생 문법(Flavor) 심층 분석

5.1. GitHub Flavored Markdown (GFM): 사실상의 표준

GitHub Flavored Markdown(GFM)은 오늘날 가장 널리 알려지고 사용되는 마크다운 플레이버로, 사실상의 표준(de facto standard) 지위를 가지고 있다.

• 정의 및 역사: GFM은 CommonMark 명세의 ’엄격한 상위 집합(strict superset)’으로 정의된다.33 이는 GFM이 CommonMark의 모든 문법과 규칙을 그대로 포함하면서, 그 위에 GitHub의 특정 요구사항을 충족시키기 위한 고유한 확장 기능들을 추가했음을 의미한다. GitHub는 초기에 ’Sundown’이라는 자체 개발 파서를 사용했으나, 2017년 일관성, 성능, 보안성을 향상시키기 위해 CommonMark의 C 참조 구현체인

cmark를 기반으로 한 새로운 파서로 전환하며 GFM 명세를 공식화했다. 이 전환은 GFM이 CommonMark와 호환되는 안정적인 기반 위에 구축되었음을 보장하는 중요한 이정표가 되었다.33

• 주요 확장 기능: GFM의 핵심은 CommonMark에 없는 실용적인 기능들을 추가한 데 있다.43

• 표 (Tables): 원본 마크다운에 없어 가장 많은 사용자들이 요구했던 기능이다. 파이프(|) 문자를 사용하여 열을 구분하고, 하이픈(-)을 사용하여 헤더와 본문을 구분하는 직관적인 문법을 제공한다. 구분선 행에 콜론(:)을 추가하여 각 열의 텍스트 정렬(왼쪽, 가운데, 오른쪽)을 제어할 수도 있다. 이 기능은 데이터를 구조화하여 보여주는 데 매우 효과적이다.44

Command	Description
git status	List all new files.
git diff	Show file differences.

• 작업 목록 (Task Lists): 목록 항목 앞에 - [ ](미완료) 또는 - [x](완료)를 추가하여 체크박스가 있는 목록을 생성할 수 있다. 이 기능은 GitHub의 이슈 및 Pull Request에서 해야 할 일을 추적하고 관리하는 데 매우 유용하게 사용되며, 프로젝트 관리의 효율성을 크게 향상시켰다.[15, 37, 47]

• Create a new repository
• Write the README file
• Push the initial commit

• 취소선 (Strikethrough): 텍스트를 두 개의 물결표(~~)로 감싸면 취소선 효과를 적용할 수 있다. (예: ~~Mistake~~) 이는 수정되었거나 더 이상 유효하지 않은 정보를 시각적으로 표시하는 데 사용된다.[15, 44]
• 자동 링크 (Autolinks): 원본 마크다운에서 URL을 링크로 만들려면 꺾쇠괄호(< >)로 감싸야 했지만, GFM에서는 www.example.com과 같은 표준 URL이나 contact@example.com과 같은 이메일 주소를 텍스트에 그대로 입력해도 자동으로 하이퍼링크로 변환해준다. 이는 사용자 편의성을 크게 높인 기능이다.[44, 48]
• 펜스 코드 블록 (Fenced Code Blocks): 기존의 4칸 들여쓰기 방식 외에, 세 개 이상의 백틱(``````)이나 물결표(~~~)로 코드 블록을 감싸는 방식을 제공한다. 시작 펜스 옆에 프로그래밍 언어 이름(예: python, javascript)을 명시하면 해당 언어에 맞는 구문 강조(Syntax Highlighting)가 적용되어 코드의 가독성을 획기적으로 개선했다. 이 기능은 CommonMark 명세에도 포함되었지만, GFM을 통해 널리 대중화되었다.[17, 44]

3.2 기타 주요 파생 문법

GFM 외에도 특정 목적을 위해 발전해 온 여러 중요한 플레이버들이 존재한다.

• Markdown Extra: PHP 개발자인 Michel Fortin이 개발한 초창기 확장 문법 중 하나이다. GFM보다 먼저 테이블 문법을 도입했으며, 각주(footnotes), 정의 목록(definition lists), 약어(abbreviations) 등 학술 문서나 기술 문서 작성에 유용한 기능들을 추가하여 마크다운의 표현력을 한 단계 끌어올렸다.14
• MultiMarkdown (MMD): Fletcher T. Penney가 개발한 MMD는 ’슈퍼셋(superset)’이라는 표현에 걸맞게 매우 강력하고 풍부한 기능을 제공한다. Markdown Extra의 기능을 대부분 포함하면서, 인용(citations), 상호 참조(cross-references), 수학식 표현(MathJax 지원), 목차 생성, 메타데이터 블록 등 책이나 긴 논문과 같은 복잡하고 규모가 큰 문서를 작성하는 데 필요한 고급 기능들을 지원한다.14
• R Markdown: 데이터 과학 및 통계 분석 커뮤니티에서 절대적인 지지를 받는 플레이버이다. R 프로그래밍 언어와 깊숙이 통합되어, 마크다운 문서 안에 R 코드 청크(chunk)를 직접 삽입하고 실행할 수 있다. 코드 실행 결과(텍스트, 표, 그래프 등)가 문서에 동적으로 포함되어, 재현 가능한(reproducible) 연구 및 분석 안내서를 작성하는 데 최적화되어 있다. HTML, PDF, Word 등 다양한 포맷으로 출력이 가능하다.31
• Obsidian Flavored Markdown: 개인 지식 관리(Personal Knowledge Management, PKM) 도구인 Obsidian에서 사용하는 플레이버이다. 위키 스타일의 내부 링크(]), 다른 노트나 이미지 파일을 문서 내에 직접 삽입하는 임베딩(![[File Name]]), 그리고 특정 문단이나 블록을 직접 참조하는 블록 참조(#^block-id)와 같은 기능을 추가하여 노트 간의 유기적인 연결과 재사용성을 극대화했다. 이는 지식의 네트워크를 구축하는 데 특화된 기능들이다.49

4. 마크다운의 강점과 약점: 비판적 고찰

4.1 강점

마크다운이 지난 20년간 폭발적인 성공을 거둔 데에는 명확하고 강력한 장점들이 뒷받침되었다.

• 간결성과 학습 용이성: 마크다운의 문법은 매우 단순하고 직관적이어서, 프로그래밍 경험이 없는 비전문가도 단 몇 분 만에 기본적인 사용법을 익힐 수 있다.13 이는 복잡한 기능을 과감히 배제하고 ’작성’이라는 행위 자체에 집중한 그루버의 설계 철학이 낳은 직접적인 결과물이다.
• 가독성과 이식성: 마크다운 원본 텍스트는 최종 렌더링 결과물과 시각적으로 매우 유사하여, 별도의 변환 과정 없이도 내용을 쉽게 파악할 수 있다.51 또한, 모든 마크다운 문서는 .md 확장자를 가진 일반 텍스트 파일이므로, 운영체제나 특정 워드 프로세서에 종속되지 않고 거의 모든 텍스트 편집기에서 열고 편집할 수 있다. 이러한 높은 이식성은 콘텐츠의 자유로운 이동과 공유를 보장한다.6
• 플랫폼 독립성 및 미래 보장성: 마크다운은 특정 운영체제나 기기에 구애받지 않고 어디서든 작성할 수 있다.6 더 중요한 것은 그 ’미래 보장성(future-proof)’이다. 100년 뒤에 특정 워드 프로세서의 파일 포맷을 열 수 없을지는 몰라도, 일반 텍스트는 컴퓨터 기술이 존재하는 한 영원히 읽을 수 있다. 이는 장기 보존이 필요한 학위 논문이나 중요한 기록물에 있어 매우 중요한 가치이다.6
• 버전 관리 용이성: 마크다운 파일은 순수한 텍스트이기 때문에 Git과 같은 버전 관리 시스템(VCS)과 완벽하게 호환된다. 코드와 마찬가지로 문서의 모든 변경 이력을 줄 단위로 추적하고, 여러 사람의 수정 사항을 병합(merge)하거나 차이점을 비교(diff)하는 작업이 매우 용이하다. 이는 ’코드로써의 문서(Docs as Code)’라는 현대적인 기술 문서 관리 패러다임의 핵심적인 기반이 된다.13
• 광범위한 생태계: 마크다운은 현재 수많은 애플리케이션과 플랫폼에서 지원된다. VS Code, Atom과 같은 코드 편집기, Obsidian, Joplin 같은 노트 앱, Jekyll, Hugo 같은 정적 사이트 생성기, Trello, Notion 같은 협업 도구에 이르기까지 광범위한 생태계가 구축되어 있어 사용자가 어떤 환경에 있든 마크다운을 활용할 수 있다.5

4.2 약점

강력한 장점에도 불구하고, 마크다운은 본질적인 한계와 약점 또한 명확히 가지고 있다.

• 표준 부재와 파편화: 이는 마크다운의 가장 치명적이고 고질적인 단점이다. CommonMark의 등장으로 어느 정도 완화되었지만, 여전히 수많은 플레이버가 존재하며 이들 간의 미묘한 문법 차이로 인해 호환성 문제가 발생한다.13 이는 마크다운의 핵심 가치인 이식성을 저해하는 가장 큰 요인이다.32
• 제한된 서식 기능: 마크다운의 단순성은 양날의 검이다. 글자색, 폰트 크기 및 종류 변경, 텍스트의 정교한 정렬, 복잡한 다단 레이아웃 등 시각적 표현을 위한 고급 서식 기능이 전무하다. 표나 각주 같은 기본적인 기능조차도 GFM과 같은 확장 문법에 의존해야 한다. 이러한 기능을 구현하기 위해서는 결국 HTML 태그를 직접 사용하는 수밖에 없다.11
• 의미론적 구조의 부재 (Lack of Semantic Structure): 마크다운은 주로 텍스트의 시각적 표현(presentation)에 초점을 맞춘다. <strong>이나 <em>과 같은 기본적인 의미론적 태그를 넘어서, ‘경고(warning)’, ‘팁(tip)’, ’중요 공지(important notice)’와 같이 콘텐츠 블록에 특정 의미(semantic)를 부여하는 표준화된 방법이 없다. 이는 콘텐츠의 기계적 처리나 재사용성을 저해하며, 다른 포맷(예: DocBook, JATS)으로 변환할 때 정보 손실을 야기할 수 있다. 문서의 구조적 의미를 표현하는 데 한계가 명확하다.11
• 보안 취약점: 마크다운이 HTML을 직접 삽입할 수 있도록 허용하는 것은 강력한 기능인 동시에 잠재적인 보안 위협이 될 수 있다. 만약 사용자가 입력한 마크다운을 필터링 없이 그대로 HTML로 변환하여 웹페이지에 표시한다면, 악의적인 사용자가 <script> 태그 등을 삽입하여 사이트 간 스크립팅(Cross-Site Scripting, XSS) 공격을 시도할 수 있다.11 GFM과 같은 최신 파서들은 이러한 위협을 완화하기 위해 잠재적으로 위험한 HTML 태그를 필터링하는 기능을 내장하고 있지만, 이는 구현에 따라 달라질 수 있는 문제이다.43

5. 활용 분야 및 생태계

5.1 개발자 도구 및 기술 문서

마크다운은 탄생 초기부터 개발자 커뮤니티와 밀접한 관계를 맺어왔으며, 현재 개발 생태계에서 없어서는 안 될 필수적인 도구로 자리 잡았다.

• GitHub 및 버전 관리 시스템: GitHub에서 README.md 파일은 해당 저장소(repository)의 ’얼굴’과 같은 역할을 한다. 프로젝트의 목적, 설치 방법, 사용법, 기여 방법 등을 담은 첫 번째 관문이다.56 또한, 이슈 트래킹, Pull Request의 코드 리뷰, 프로젝트 위키 등 GitHub 내의 거의 모든 텍스트 입력 영역에서 GFM이 표준으로 사용되어 개발자 간의 원활한 소통을 돕는다.7
• 정적 사이트 생성기 (Static Site Generators): Jekyll, Hugo, MkDocs, Docusaurus와 같은 도구들은 마크다운으로 작성된 텍스트 파일들을 완전한 웹사이트로 변환해준다.59 개발자들은 복잡한 웹 기술 없이도 익숙한 마크다운 문법만으로 기술 블로그, 프로젝트 문서 사이트, 포트폴리오 등을 빠르고 쉽게 구축하고 배포할 수 있다.
• 기술 문서 작성 (Technical Writing): Adobe, Google, Microsoft 등 수많은 기술 기업들이 공식 기술 문서를 작성하고 관리하는 데 마크다운을 적극적으로 활용하고 있다.61 ‘Docs as Code’ 철학에 따라 문서를 코드와 동일한 버전 관리 시스템에서 관리함으로써, 문서의 변경 이력을 추적하고 여러 작성자가 협업하며 품질을 유지하는 것이 용이해졌다.

5.2 개인 지식 관리 및 노트 작성

마크다운은 개인 지식 관리(PKM) 및 노트 작성 분야에서도 폭발적인 인기를 얻고 있다. Obsidian, Joplin, Bear, Simplenote, Typora 등 수많은 노트 애플리케이션이 마크다운을 핵심 편집 언어로 채택했다.55

이러한 현상은 단순히 마크다운의 문법이 편리하기 때문만은 아니다. 이는 과거의 노트 앱들이 사용했던 독점적인(proprietary) 파일 포맷이나 데이터베이스 시스템에 대한 반작용으로 해석될 수 있다. 사용자들은 특정 기업의 서비스에 자신의 모든 데이터가 종속되는 ‘데이터 잠금(data lock-in)’ 현상에 피로감을 느끼고, 자신의 데이터를 온전히 소유하고 통제하고자 하는 욕구가 커졌다.6 마크다운은 이러한 요구에 완벽하게 부합하는 해결책이었다. 일반 텍스트 기반의 파일들은 특정 플랫폼에서 자유로우며, 폴더 구조를 통해 사용자가 직접 관리할 수 있다. Obsidian이나 Logseq 같은 최신 PKM 도구들은 이러한 ‘로컬 우선(local-first)’, ‘일반 텍스트 기반’ 철학을 중심으로 구축되어 사용자에게 데이터의 완전한 소유권을 보장한다. 따라서 PKM 분야에서 마크다운의 부상은 기술적 선택을 넘어, 데이터 주권과 지속 가능성을 중시하는 철학적 움직임의 결과물이라 할 수 있다.

5.3 콘텐츠 저작 및 기타

마크다운의 활용 범위는 개발자와 기술 문서를 넘어 일반적인 콘텐츠 제작 영역으로 계속 확장되고 있다.

• 블로그 및 콘텐츠 관리 시스템 (CMS): Ghost와 같은 최신 블로깅 플랫폼은 마크다운을 기본 편집기로 채택하고 있으며, 세계에서 가장 널리 쓰이는 CMS인 WordPress 역시 플러그인을 통해 마크다운을 지원한다. 이를 통해 작성자들은 복잡한 WYSIWYG 편집기 대신 글쓰기 자체에 집중할 수 있다.5
• 프레젠테이션: Marp, Remark.js, Deckset과 같은 도구들을 사용하면 마크다운 텍스트만으로 프레젠테이션 슬라이드를 제작할 수 있다.5 이는 디자인에 들이는 시간을 줄이고 내용에 집중하여 빠르게 발표 자료를 만들 수 있는 효율적인 방법이다.
• 이메일 및 메시징: Gmail, Outlook 등에서 브라우저 확장 프로그램을 통해 이메일을 마크다운으로 작성할 수 있으며, Discord, Slack, Mattermost와 같은 협업 메시징 도구에서도 코드 조각이나 간단한 텍스트 서식을 위해 마크다운 문법을 지원한다.6

6. 주요 마크업 언어와의 비교 분석

마크다운의 위상을 정확히 파악하기 위해서는 유사한 목적을 가진 다른 경량 마크업 언어와의 비교가 필수적이다. 여기서는 가장 대표적인 경쟁자인 AsciiDoc과 reStructuredText를 중심으로 비교 분석한다.

6.1 Markdown vs. AsciiDoc

• 유사점: 두 언어 모두 가독성이 높은 일반 텍스트를 기반으로 하는 경량 마크업 언어라는 공통점을 가진다. 사용자가 복잡한 태그 대신 간단한 문법으로 구조화된 문서를 작성할 수 있도록 돕는다는 목표를 공유한다.65
• 차이점: 가장 큰 차이는 설계 철학에 있다. 마크다운이 최소한의 기능만을 제공하는 ‘미니멀리즘’ 철학을 따른다면, AsciiDoc은 복잡한 기술 문서 작성에 필요한 대부분의 기능을 기본적으로 내장한 “배터리 포함(batteries-included)” 철학을 따른다.60 예를 들어, 표, 경고문(admonition), 문서 간 상호 참조, 다른 파일 내용 포함(include directive) 등은 AsciiDoc의 표준 기능이지만, 마크다운에서는 이를 구현하기 위해 특정 플레이버에 의존하거나 HTML을 직접 사용해야 한다.
• 결론: 두 언어는 기능성과 단순성 사이의 명확한 트레이드오프 관계를 보여준다. 간단한 문서, README 파일, 블로그 포스트와 같이 빠른 작성이 중요한 경우에는 마크다운의 단순함이 큰 장점이 된다. 반면, 여러 챕터로 구성된 책, 공식 기술 매뉴얼, 복잡한 다중 페이지 문서 시스템(예: Antora 프레임워크)을 구축하는 경우에는 AsciiDoc의 강력하고 표준화된 기능이 훨씬 더 적합하다.66

6.2 Markdown vs. reStructuredText (reST)

• 유사점: 두 언어 모두 기술 문서 작성에 널리 사용되며, 일반 텍스트로 작성하여 다른 포맷으로 변환하는 것을 목표로 한다.67
• 차이점: reStructuredText(reST)는 마크다운보다 문법이 더 복잡하고 엄격하지만, 그 대가로 훨씬 뛰어난 확장성과 강력한 기능을 제공한다.68 reST의 진정한 힘은 Python 기반의 문서 생성 도구인 Sphinx와 결합될 때 발휘된다. Sphinx는 reST 문서를 분석하여 코드 주석에서 API 참조 문서를 자동으로 생성하고, 정교한 상호 참조 네트워크를 구축하며, 일관된 테마를 적용하는 등 고도로 구조화된 전문적인 기술 문서를 만드는 데 필요한 거의 모든 기능을 제공한다.68
• 결론: reST는 특히 Python 생태계에서 강력한 지지를 받는 전문적인 문서화 도구이다. 고도로 구조화되고 일관성이 요구되는 대규모 프로젝트 문서에 최적화되어 있다. 반면, 마크다운은 낮은 진입 장벽과 범용성을 무기로 개발자 커뮤니티 전반에 걸쳐 훨씬 더 넓은 사용자층을 확보했다. reST가 ’전문가를 위한 정밀 도구’라면, 마크다운은 ’모두를 위한 만능 도구’에 가깝다고 할 수 있다.

6.3 Table 2: 마크다운, AsciiDoc, reStructuredText 기능 비교

평가 기준	Markdown	AsciiDoc	reStructuredText (reST)
문법 단순성	매우 높음. 직관적이고 배우기 쉬움.	중간. 마크다운보다 기능이 많아 복잡함.	낮음. 엄격하고 복잡한 지시어(directive) 기반 문법.
가독성 (원본)	매우 높음. 최종 결과물과 거의 유사함.	높음. 마크다운과 유사하나 지시어가 포함됨.	중간. 지시어와 역할(role)로 인해 원본 가독성이 다소 떨어짐.
표준화 수준	낮음. CommonMark가 있으나 여전히 Flavor가 많음.	높음. 단일 표준으로 일관성이 보장됨.	매우 높음. Doc-utils에 의해 엄격하게 관리됨.
핵심 기능 세트	최소한의 기능만 제공 (기본 서식, 링크).	풍부함 (표, 각주, 경고문, 상호 참조 등 내장).	풍부함 (표, 각주, 지시어, 역할 등 내장).
확장성	중간. Flavor나 HTML을 통해 확장.	높음. 사용자 정의 매크로 및 블록 지원.	매우 높음. 지시어와 역할을 통한 무한한 확장 가능.
도구 생태계	매우 넓음. 범용적이며 수많은 도구에서 지원.	중간. Asciidoctor, Antora 등 강력한 전문 도구 존재.	높음. 특히 Sphinx와의 결합이 강력함 (Python 생태계).
주요 사용 사례	README, 블로그, 노트, 간단한 문서.	기술 서적, 공식 매뉴얼, 복잡한 문서 시스템.	API 문서, 대규모 프로젝트 공식 문서, Python 관련 문서.

자료 출처: 60

7. 결론: 마크다운의 현재와 미래

7.1 지난 20년의 유산

마크다운은 지난 20년간 디지털 문서 작성의 패러다임을 근본적으로 바꾸어 놓았다. 그 핵심 유산은 복잡한 서식 도구의 방해 없이 사용자가 ’작성’이라는 행위 자체에 온전히 집중할 수 있도록 만들었다는 점이다. 존 그루버의 ‘가독성 최우선’ 철학은 기술적 정교함이나 기능의 풍부함보다 인간의 인지적 편의를 우선시했고, 이 선택은 마크다운이 기술 전문가뿐만 아니라 일반 사용자에게까지 폭발적으로 확산되는 핵심 원동력이 되었다. 마크다운은 콘텐츠 제작의 진입 장벽을 극적으로 낮춤으로써, 더 많은 사람이 자신의 생각과 지식을 디지털 세상에 공유할 수 있는 길을 열었다.

7.2 단순성과 확장성의 영원한 긴장

마크다운의 역사는 그 본질에 내재된 두 가치, 즉 ’단순성’과 ‘확장성’ 사이의 끊임없는 긴장 관계의 역사로 요약될 수 있다. 창시자는 마크다운을 작고 단순한 도구로 유지하고자 했지만, 사용자 커뮤니티는 더 많은 기능과 복잡한 요구사항을 충족시키기 위한 확장을 끊임없이 요구했다. 이 긴장 관계는 표준 부재와 플레이버의 난립이라는 혼란을 낳았고, CommonMark와 GFM의 등장은 이러한 긴장을 해소하고 실용적인 합의점을 찾으려는 생태계의 자정 노력의 산물이었다. 그러나 이 근본적인 딜레마는 여전히 마크다운의 정체성을 규정하는 핵심 요소로 남아있다.

7.3 구조화된 콘텐츠 시대의 도전

현대의 디지털 콘텐츠 패러다임은 인간이 읽기 좋은 문서를 넘어, 기계가 읽고 재사용할 수 있는 ’구조화된 데이터(structured data)’로 빠르게 이동하고 있다. 콘텐츠를 독립적인 구성 요소로 분해하고, 각 요소에 명확한 의미론적(semantic) 정보를 부여하여 다양한 맥락에서 재조합하는 것이 중요해지고 있다.12 마크다운의 약한 의미론적 구조는 이러한 새로운 패러다임 앞에서 명백한 도전에 직면해 있다.11 이 문제를 해결하기 위한 시도로, 마크다운 문법 내에 React 컴포넌트(JSX)를 직접 사용할 수 있게 하는 MDX(Markdown + JSX)와 같은 프로젝트가 주목받고 있다.60 이는 마크다운의 간결한 작성 경험을 유지하면서도 컴포넌트 기반의 강력한 구조를 결합하려는 시도로, 마크다운의 미래 진화 방향을 엿볼 수 있게 하는 중요한 단서이다.

7.4 최종 전망

결론적으로 마크다운은 그 자체로 모든 문제를 해결하는 완벽한 언어가 아니다. 그러나 그 기반은 가장 보편적이고 미래 보장적인 ’일반 텍스트’이며, 이 단순함은 특정 기술이나 플랫폼의 흥망성쇠를 초월하는 영속성을 부여한다. 마크다운의 가장 위대한 가치는 복잡한 기술 세계로 들어가는 ’낮은 문턱’이자 ’단순한 시작점’으로서의 역할에 있다. 이는 새로운 사용자를 콘텐츠 제작의 세계로 이끄는 ‘트로이 목마’ 전략과도 같다.32 앞으로도 마크다운은 단독으로 존재하기보다는, Python, R, JavaScript 컴포넌트, 데이터베이스 등 다른 강력한 기술들과 결합하며 그 생명력을 이어갈 것이다. 마크다운은 언제나 글쓰기를 시작하는 가장 쉽고 편안한 방법을 제공할 것이며, 그것이 바로 이 언어의 가장 위대한 유산이자 미래 가치일 것이다.

8. 참고 자료

1. 마크다운 - 위키백과, 우리 모두의 백과사전, https://ko.wikipedia.org/wiki/%EB%A7%88%ED%81%AC%EB%8B%A4%EC%9A%B4
2. 마크다운(Markdown)이란? - Dooray!, https://nhnent.dooray.com/htmls/guides/markdown_ko_KR.html
3. 마크다운에 대하여, https://tinydew4.gitbooks.io/markdown/about/
4. Introduction to Markup - GitHub Pages, https://cmohge1.github.io/lrbs-digital-editing-intro-2019/Intro-to-markup.pdf
5. [무료] 프레젠테이션 슬라이드 제작에 특화된 마크다운 편집기 ‘Marp’ - the Mac - 티스토리, https://macnews.tistory.com/4658
6. Getting Started | Markdown Guide, https://www.markdownguide.org/getting-started/
7. Markdown definition - Sanity, https://www.sanity.io/glossary/markdown
8. Markdown - Wikipedia, https://en.wikipedia.org/wiki/Markdown
9. Markdown - Daring Fireball, https://daringfireball.net/projects/markdown/
10. Markdown Syntax Documentation - Daring Fireball, https://daringfireball.net/projects/markdown/syntax
11. Why You Should and Should Not Use Markdown | by Peter Conrad | Medium, https://stymied.medium.com/why-you-should-and-should-not-use-markdown-1b9d70987792
12. Thoughts On Markdown - Smashing Magazine, https://www.smashingmagazine.com/2022/02/thoughts-on-markdown/
13. 마크다운(Markdown) 사용법 - GitHub Gist, https://gist.github.com/ihoneymon/652be052a0727ad59601
14. Comparing Markdown Flavors - MetaBrainz Tickets, https://tickets.metabrainz.org/secure/attachment/11757/markdown_comparison.pdf
15. Markdown Cheat Sheet, https://www.markdownguide.org/cheat-sheet/
16. Basic Syntax | Markdown Guide, https://www.markdownguide.org/basic-syntax/
17. 마크다운(MarkDown) 작성 문법 총정리 - Inpa Dev ‍ - 티스토리, https://inpa.tistory.com/entry/MarkDown-%F0%9F%93%9A-%EB%A7%88%ED%81%AC%EB%8B%A4%EC%9A%B4-%EB%AC%B8%EB%B2%95-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC
18. 마크다운(MarkDown) 사용법 총정리 - HEROPY.DEV, https://www.heropy.dev/p/B74sNE
19. Basic formatting syntax - Obsidian Help, https://help.obsidian.md/syntax
20. Markdown Basics - Daring Fireball, https://daringfireball.net/projects/markdown/basics
21. The Markdown elements outlined in John Gruber’s design document. - GitHub, https://gist.github.com/hasancaslan/ae757b33ef1946a6f8ce20aae2feabf4
22. Markdown 문법 총정리, https://velog.io/@sisofiy626/Markdown-%EB%AC%B8%EB%B2%95-%EC%B4%9D%EC%A0%95%EB%A6%AC
23. 사실은 내가 보기위한 마크다운 문법설명서 - 2. 리스트와 인용구 - GitHub Gist, https://gist.github.com/ninanung/73addc0263b34da5f021d2f02a356b7f
24. Markdown Syntax for Files, Widgets, Wikis - Azure DevOps | Microsoft Learn, https://learn.microsoft.com/en-us/azure/devops/project/wiki/markdown-guidance?view=azure-devops
25. Markdown(마크다운) 설명 및 사용법, https://malgun-gothic.tistory.com/2
26. r/programming - Standard Flavored Markdown - Reddit, https://www.reddit.com/r/programming/comments/2fdsan/standard_flavored_markdown/
27. List item - CommonMark Spec, https://spec.commonmark.org/0.26/
28. 마크다운(MarkDown) 문법 정리 - JJukE’s Brain - 티스토리, https://jjuke-brain.tistory.com/entry/%EB%A7%88%ED%81%AC%EB%8B%A4%EC%9A%B4MarkDown-%EB%AC%B8%EB%B2%95-%EC%A0%95%EB%A6%AC
29. 기초 Markdown(마크다운) 문법 봅시다~ - About IT Tutorials, https://azanewta.tistory.com/41
30. Extended Syntax - Markdown Guide, https://www.markdownguide.org/extended-syntax/
31. Variants and Flavors of Markdown - Luis Llamas, https://www.luisllamas.es/en/markdown-flavors-and-variants/
32. The pros and cons of using Markdown - passo.uno, https://passo.uno/pros-cons-markdown/
33. A formal spec for GitHub Flavored Markdown, https://github.blog/engineering/user-experience/a-formal-spec-for-github-markdown/
34. High Performance CommonMark and Github Markdown Rendering in R - Docs, https://docs.ropensci.org/commonmark/
35. commonmark - NPM, https://www.npmjs.com/package/commonmark
36. commonmark-java/CHANGELOG.md at main - GitHub, https://github.com/commonmark/commonmark-java/blob/main/CHANGELOG.md
37. GitLab Flavored Markdown (GLFM), https://docs.gitlab.com/user/markdown/
38. GitHub is now using CommonMark and a modified version of cmark, https://talk.commonmark.org/t/github-is-now-using-commonmark-and-a-modified-version-of-cmark/2365
39. Java library for parsing and rendering CommonMark (Markdown) - GitHub, https://github.com/commonmark/commonmark-java
40. CommonMark: Standard Markdown - Racket Documentation, https://docs.racket-lang.org/commonmark/index.html
41. github.github.com, https://github.github.com/gfm/#:~:text=GitHub%20Flavored%20Markdown%2C%20often%20shortened,a%20strict%20superset%20of%20CommonMark.
42. Understanding CommonMark and GFM in the Context of iOS Markdown Rendering, https://ajkueterman.medium.com/understanding-commonmark-and-gfm-in-the-context-of-ios-markdown-rendering-16af9574cd8f
43. GitHub Flavored Markdown Spec, https://github.github.com/gfm/
44. Markdown Cheatsheet - GitHub, https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet
45. Markdown Tables - GeeksforGeeks, https://www.geeksforgeeks.org/html/markdown-tables/
46. Organizing information with tables - GitHub Docs, https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables
47. Use GFM style with markdown-it and mdformat instead of commonmark - Reddit, https://www.reddit.com/r/learnpython/comments/vmobno/use_gfm_style_with_markdownit_and_mdformat/
48. GitHub flavored markdown (GFM) - MDX, https://mdxjs.com/guides/gfm/
49. Obsidian Flavored Markdown, https://help.obsidian.md/obsidian-flavored-markdown
50. Markdown - Simple to write, limited features - MonsterWriter, https://www.monsterwriter.com/markdown/markdown-benefits-and-drawbacks.html
51. 마크다운의 장점: RAG-LLM에서 텍스트 추출과 임베딩의 용이성, https://medtalk.tistory.com/entry/%EB%A7%88%ED%81%AC%EB%8B%A4%EC%9A%B4%EC%9D%98-%EC%9E%A5%EC%A0%90-RAG-LLM%EC%97%90%EC%84%9C-%ED%85%8D%EC%8A%A4%ED%8A%B8-%EC%B6%94%EC%B6%9C%EA%B3%BC-%EC%9E%84%EB%B2%A0%EB%94%A9%EC%9D%98-%EC%9A%A9%EC%9D%B4%EC%84%B1
52. www.markdownguide.org, https://www.markdownguide.org/getting-started/#:~:text=Markdown%20is%20future%20proof.,using%20a%20text%20editing%20application.
53. How is Markdown future proof since it may no longer be supported in the, https://www.reddit.com/r/Markdown/comments/lwi4e2/how_is_markdown_future_proof_since_it_may_no/
54. Markdown Code Reviews - Engineering Fundamentals Playbook - Microsoft Open Source, https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/markdown/
55. Tools - Markdown Guide, https://www.markdownguide.org/tools/
56. How to Write a Good README File for Your GitHub Project - freeCodeCamp, https://www.freecodecamp.org/news/how-to-write-a-good-readme-file/
57. Best Practices For An Eye Catching GitHub Readme - Hatica, https://www.hatica.io/blog/best-practices-for-github-readme/
58. About READMEs - GitHub Docs, https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
59. What Is Markdown? Uses and Benefits Explained - Medium, https://medium.com/@AlexanderObregon/what-is-markdown-uses-and-benefits-explained-947300e1f955
60. Markdown, Asciidoc, or reStructuredText - a tale of docs-as-code - Dewan Ahmed, https://www.dewanahmed.com/markdown-asciidoc-restructuredtext/
61. Markdown (optional) | Technical Writing - Google for Developers, https://developers.google.com/tech-writing/one/markdown
62. How to use Markdown for writing documentation | Adobe Experience Cloud, https://experienceleague.adobe.com/en/docs/contributor/contributor-guide/writing-essentials/markdown
63. www.google.com, https://www.google.com/search?q=markdown+note+taking+apps
64. Best Markdown Note Taking Apps for 2025 - Tool Finder, https://toolfinder.co/lists/best-markdown-notetaking-apps
65. I Wish AsciiDoc was more popular - pdx.su, https://pdx.su/blog/2023-02-05-asciidoc-and-markdown/
66. Markdown vs AsciiDoc - which is better? | James Read’s Code, Containers & Cloud blog, https://blog.jread.com/posts/markdown-vs-asciidoc/
67. Common markup for Markdown and reStructuredText - GitHub Gist, https://gist.github.com/dupuy/1855764
68. md vs .rst / community / Discussion #86067 - GitHub, https://github.com/orgs/community/discussions/86067
69. reStructuredText v.s. Markdown - - - ESP-Docs User Guide latest documentation, https://docs.espressif.com/projects/esp-docs/en/latest/introduction/restructuredtext-vs-markdown.html